The present invention relates generally to tracking and managing information for multiple groups or sources, and in particular to tracking and managing information relating to the development of a particular version or release of a software product.
Large software companies typically have trouble keeping track of the progress of development and other aspects of various software releases at both a high-level and a lower, more detailed level. This can be problematic, as executive management may wish to know or easily determine the status of an overall application release in general (i.e., the high-level status). Similarly, development managers may be interested in tracking the daily progress of their engineers with regard to specific tasks, metrics, or other performance items. In one example, this translates into a percentage complete of the developers' coding tasks (i.e., the detailed-level status.) Current systems and approaches lack the ability to track both levels of data in one system at the same time, while providing an adequate high-level status derived from the detail-level data.
One previous solution was to manually update a high-level status report. Development managers would individually keep track of their engineering work in separate project plans, in an application such as Oracle Projects from Oracle Corporation of Redwood Shores, Calif., or Microsoft Project from Microsoft Corporation of Redmond, Wash. The development managers would check regularly (e.g., weekly) to determine how their engineers were progressing, then estimate and enter a “percentage complete” into a high-level reporting system. The managers might also write their own ad hoc reports in the technology of their choice if their project data was in a database, and use these various reports to demonstrate progress to upper management. While such approaches allow for flexibility with respect to development team styles and approaches, it can be difficult to integrate the various approaches and time consuming for managers to constantly generate a current high level view. Further, it can be difficult for a manager to estimate things like a completion date when the manager does not know the status of a portion from another team upon which the date depends. The high-level reports also are based on manually-entered data, which results in reports that show only a snapshot-in-time of the release progress, and results in a high frequency of data errors since updates are done manually and not derived directly from the project data source.
Another solution was to save project plan files to a central server, using an application such as Microsoft Project Server. The data from the project plan files then could be saved into appropriate tables for subsequent querying and reporting. These reports allow for both high level and detailed level views. While such an approach is beneficial from the reporting standpoint, it typically requires using standardized approaches that might not be optimal for various development teams. Such an approach might require a team to change the way it enters or tracks data, which can be time consuming and/or undesirable to the team manager. Further, these approaches might not be sufficiently customizable to address new concerns as they arise. Further still, such a solution is not particularly easy to use in many instances, and can be relatively slow.